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Abstract.  We  are  investigating  a  component-based  approach  for  formal 
design  of  distributed  systems.  In  this  paper,  we  introduce  the  framework 
we  use  for  specification,  composition  and  communication  and  we  apply 
it  to  an  example  that  highlights  the  different  aspects  of  a  compositional 
design,  including  top-down  and  bottom-up  phases,  proofs  of  composition, 
refinement  proofs,  proofs  of  program  texts,  and  component  reuse. 
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1  A  Compositional  Approach 

1.1  Introduction 

Component  technology  is  becoming  increasingly  popular.  Microsoft’s  COM,  Java¬ 
Soft’s  beans,  CORBA,  and  new  trade  magazines  devoted  to  component  technol¬ 
ogy  attest  to  the  growing  importance  of  this  area.  Component-based  software 
development  is  having  an  impact  in  the  development  of  user  interfaces.  Such 
systems  often  have  multiple  threads  (loci  of  control)  executing  in  different  com¬ 
ponents  that  are  synchronized  with  each  other. 

These  systems  are  examples  of  reactive  systems  in  which  components  inter¬ 
act  with  their  environments.  Component  technology  has  advantages  for  reactive 
systems,  but  it  also  poses  important  challenges  including  the  following. 

—  How  do  we  specify  components?  Specifications  must  deal  with  both  progress 
and  safety,  and  they  must  capture  the  relationship  between  each  component 
and  its  environment.  What  technologies  will  support  large  repositories  of 
software  components,  possibly  even  world-wide  webs  of  components,  such 
that  component  implementations  can  be  discovered  given  component  speci¬ 
fications? 
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—  Electronic  circuit  design  is  an  often  cited  metaphor  for  building  software 
systems  using  component  technologies.  Phrases  such  as  plug  and  play ,  and 
wiring  components  together,  are  used  in  software  design.  These  approaches 
to  software  design  will  work  only  if  there  are  systematic  methods  of  proving 
specifications  of  composed  systems  from  specifications  of  components. 
Further,  we  would  like  to  propose  methods  in  which  the  proof  obligations 
for  the  designer  who  puts  components  together  is  made  easier  at  the  ex¬ 
pense  of  the  component  designer.  The  idea  is  that  component  designers  add 
component  specifications,  implementations,  and  proofs  into  a  repository.  An 
implementation  of  a  component  may,  in  turn,  be  a  composition  of  other  com¬ 
ponents.  We  want  the  composer’s  work  to  become  easier  by  exploiting  the 
effort  in  specification,  implementation  and  proof  that  is  invested  in  building 
the  component  repository. 

—  Mechanical  proof  checkers  and  theorem  provers  can  play  an  important  role 
in  building  high-confidence  repositories  of  software  components,  though  the 
widespread  use  of  these  technologies  may  be  decades  away.  The  challenge 
is  to  develop  theories  of  composition  that  can  be  supported  by  mechanical 
provers. 


1.2  Proposition 

The  basis  for  our  framework  is  the  Unity  formalism  which  provides  a  way  to 
describe  fair  transition  systems  and  which  uses  a  small  set  of  temporal  logic 
operators  which  appear  well  suited  for  many  applications.  It  is  extended  with  a 
theory  of  composition  which  relies  on  two  intuitive  forms  of  interaction:  existen¬ 
tial  (a  system  property  holds  if  it  holds  in  at  least  one  component)  and  universal 
(a  system  property  holds  if  it  holds  in  all  components).  We  also  add  a  new  tempo¬ 
ral  operator  ( follows )  which  allows  us  to  represent  asynchronous  point-to-point 
communication  at  a  logical  level,  while  using  only  monotonic  distributed  (i.e. 
writable  by  one  component  only)  variables. 

These  choices  restrict  the  expressive  power  of  the  framework:  we  do  not  deal 
with  any  temporal  specification,  any  form  of  composition,  any  type  of  commu¬ 
nication.  This  is  a  way  in  which  we  obtain  something  manageable.  However,  we 
need  to  know  if  such  a  framework  can  be  applied  to  a  wide  class  of  problems 
and  if  it  leads  to  simple  and  intuitive  proofs.  These  two  points  can  be  explored 
by  using  the  framework  to  design  several  distributed  systems. 

Through  the  example  described  in  this  paper,  we  show  that  this  framework 
can  be  used  to  specify  generic  and  specific  components,  to  describe  communica¬ 
tion  between  them,  to  handle  refinement  proofs  (classical  Unity  proofs)  related 
to  top-down  steps,  program  text  correctness  proofs  (“almost”  classical  Unity 
proofs)  and  compositional  proofs  related  to  bottom-up  steps. 

The  remainder  of  the  paper  is  organized  as  follows.  In  the  next  section,  we 
formally  define  the  different  aspects  of  the  framework  we  are  using.  The  following 
section  presents  the  architecture  of  a  resource  allocation  example  and  introduces 
the  required  formal  steps  we  have  to  complete  in  order  to  achieve  the  design. 


2 


The  next  sections  are  each  devoted  to  a  part  of  this  design,  namely  the  high- 
level  decomposition,  the  clients  design,  the  decomposition  of  the  allocator  into 
a  simpler  allocator  and  finally  the  design  of  this  simpler  allocator.  One  proof 
of  each  kind  (refinement,  composition  and  program  text  correctness)  is  given  in 
the  paper.  All  other  proofs  are  detailed  in  appendixes. 

2  Framework 

The  framework  we  use  is  based  on  a  UNiTY-like  logic  and  programming  nota¬ 
tion  [1, 6].  The  traditional  Unity  form  of  composition  (union)  is  used.  However, 
at  the  logical  level,  we  use  the  notions  of  existential  and  universal  properties. 
Especially,  a  guarantees  operator,  that  provides  existential  specifications,  is  in¬ 
troduced  [2, 3].  We  further  extend  Unity  with  an  abstraction  of  communication, 
based  on  temporal  operators  described  in  [4,9]. 


2.1  Basis 

A  program  (describing  a  component  behavior)  consists  of  a  set  of  typed  variables, 
an  initially  predicate,  which  is  a  predicate  on  program  states,  a  finite  set  of 
atomic  commands  C,  and  a  subset  D  of  C  of  commands  subjected  to  a  weak 
fairness  constraint:  every  command  in  D  must  be  executed  infinitely  often.  The 
set  C  contains  at  least  the  command  skip  which  leaves  the  state  unchanged. 

Program  composition  is  defined  to  be  the  union  of  the  sets  of  variables  and  the 
sets  C  and  D  of  the  components,  and  the  conjunction  of  the  initially  predicates. 
Such  a  composition  is  not  always  possible.  Especially,  composition  must  respect 
variable  locality  and  must  provide  at  least  one  initial  state  (the  conjunction  of 
initial  predicates  must  be  logically  consistent).  We  use  F  *  G  to  denote  that 
programs  F  and  G  can  be  composed.  Then,  the  system  resulting  from  that 
composition  is  denoted  by  FjjG. 

To  specify  programs  and  to  reason  about  their  correctness,  we  use  Unity 
logical  operators  as  defined  in  [6].  However,  when  dealing  with  composition,  one 
must  be  careful  wether  to  use  the  strong  or  the  weak  form  of  these  operators. 
The  strong  (sometimes  called  inductive)  form  is  the  one  obtained  from  the  wp 
quantification  without  using  the  substitution  axiom  [1,6].  The  weak  form  is  either 
the  one  obtained  when  using  the  substitution  axiom  or  the  one  defined  from  the 
strongest  invariant  (which  are  equivalent)  [6,8].  Strong  operators  are  subscript 
with  s  and  weak  operators  are  subscript  with  w.  No  subscript  means  that  either 
form  can  be  used.  The  strong  form  of  an  operator  is  logically  stronger  than  the 
weak  form.  Note  that  transient  has  no  weak  form  and  leads-to  has  no  strong 
form,  and  that  always  is  the  weak  form  of  invariant  (which  is  strong).  These 
operators  are  defined  as  follows,  for  any  state  predicates  p  and  q  (SI  denotes  the 
strongest  invariant  of  the  program) : 

init  p  =  [initially  =>  p] 

transient  p  =  (3c  :  c  €  D  :  p  =>  wp.c.^p) 
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p  nexts  q 
stables  p 
invariant  p 
p  nextff  q 
stable,,,  p 
always  p 


A_ 

A 

A_ 

A_ 

A_ 

A 


{Vc  :  c  G  D  :  p  =>•  wp.c.q) 
p  nexts  P 

(init  p)  A  (stables  p) 
(SI Ap)  nexts  <1 
p  nextw  p 


[SI^p\ 


The  leads-to  operator,  denoted  by  ,  is  the  strongest  solution  of: 

Transient  :  [  transient  q  =>•  true  q  ] 

Implication  :  [p  =>  q]  =$■  [p  t-»  q] 

Disjunction  :  For  any  set  of  predicates  S: 

[  (Vp  :  p  G  S  :  p  q)  =>  {Bp  :  p  €  S  :  p)  q  ] 
Transitivity  :[p  i->  q  Aq  r  =>  p  r] 

PSP  :  [  p  i->  q  A  s  next  w  t  =$■  (pAs)  (gAs)V  (->  s  A  t)  ] 

X  ■  F  means  that  property  X  holds  in  program  F.  Traditionally,  monotonicity 
is  expressed  with  a  set  of  stable  properties.  In  order  to  avoid  the  repetition  of 
this  set  of  stable  properties,  we  define  the  shortcut: 

x  -F  =  (Vfc  ::  stable^  k  ^  x  ■  F) 

which  means  that  x  never  decreases  in  F  in  isolation  (the  weak  form  of  stable  is 
used  and  nothing  is  said  about  x  when  F  is  composed  with  other  components). 
When  there  is  no  ambiguity,  we  omit  the  order  relation  and  simply  write  x  /\ 
Since  we  are  dealing  with  distributed  systems,  we  assume  no  variable  can 
be  written  by  more  than  one  component1.  We  consider  three  kinds  of  variables: 
input  ports,  output  ports  and  local  variables.  Input  ports  can  only  be  read  by  the 
component;  output  ports  and  local  variables  can  be  written  by  the  component 
and  by  no  other  component. 

The  fact  that  an  output  port  or  a  local  variable  cannot  be  written  by  an¬ 
other  component  is  referred  to  as  the  locality  principle.  Formally,  if  variable  v 
is  writable  by  component  F  and  env  is  a  possible  environment  of  F  (F  *  env) . 
then: 

Vfc  ::  stables  v  =  k  ■  env 
i.e.,  v  is  left  unchanged  by  F’s  environment. 


2.2  Composition 

We  use  a  compositional  approach  introduced  in  [2,3],  based  on  existential  and 
universal  characteristics.  A  property  is  existential  when  it  holds  in  any  system 
in  which  at  least  one  component  has  the  property.  A  property  is  universal  when 

1  Strictly  speaking,  a  component  local  variable  may  be  read  by  another  component, 
but  we  do  not  use  that  possibility. 
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it  holds  in  any  system  in  which  all  components  have  the  property.  Of  course,  any 
existential  property  is  also  universal.  We  use  the  formal  definition  of  [5]  which 
is  slightly  different  from  the  original  definition  in  [3]: 

X  is  existential  =  {VF,G  :  F  *  G  :  X  ■  F  V  X  ■  G  =>  X  ■  F|G) 

X  is  universal  =  {VF,G  :  F  *  G  :  X  ■  F  A  X  ■  G  ^  X  ■  f\g) 

Another  element  of  the  theory  is  the  guarantees  operator,  from  pairs  of  properties 
to  properties.  Given  program  properties  X  and  Y .  the  property  X  guarantees  Y 
is  defined  by: 

X  guarantees  Y  F  =  (VG  :  F  *G  :  (X  ■  FJG)  =>  (Y  •  F|G)) 

Properties  of  type  init,  transient  and  guarantees  are  existential  and  properties 
of  type  nexts,  stables  and  invariant  are  universal.  All  other  types  are  neither 
existential  nor  universal,  but  can  appear  on  the  right-hand  side  of  a  guarantees 
to  provide  an  existential  property. 

2.3  Communication 

All  the  communication  involved  in  a  system  is  described  with  input  and  out¬ 
put  ports.  Formally,  an  input  (resp.  output)  port  is  the  history  of  all  messages 
received  (resp.  sent)  through  this  port.  Note  that  ports  are  monotonic  with  re¬ 
spect  to  the  prefix  relation.  We  need  to  introduce  a  temporal  operator  to  describe 
communication  delays  between  these  ports,  as  well  as  some  notations  to  handle 
easily  finite  sequences  of  messages. 

Follows.  To  represent  the  unbounded  nondeterministic  delay  introduced  by 
some  components  (including  the  underlying  network) ,  we  use  a  follows  temporal 
operator  inspired  form  [4,9]. 

Definition  1  (E).  For  any  pair  of  state  expressions  (in  particular  variables) 
x  and  ‘x,  and  an  order  relation  ^ ,  we  define  ‘i|i  (“  ‘x  follows  x”)  with  respect 
to 

‘ill  =  (, X  /*<;)  A  (‘x  /*<;)  A  (always  ‘x  ^  x)  A  (Vfc 

Intuitively,  ‘i|i  means  that  x  and  ‘x  are  monotonic  and  ‘x  is  always  trailing 
x  (wrt  the  order  ^),  but  that  some  liveness  always  works  at  reducing  the  gap. 

Then,  follows  can  be  used  in  conjunction  with  functions  on  histories  to  de¬ 
scribe  different  kinds  of  transformational  components.  Deterministic  components 
are  described  with  specifications  of  the  form  “Out&  f.In ”,  while  nondetermin¬ 
istic  components  use  the  “f.Out&  In ”  form.  In  particular,  network  components 
(wires)  are  specified  by  “OuttS  In 

The  following  properties  are  referred  to  as  “follows  theorems” : 

‘1B1A  /  monotonic  =>  /.‘i|  f.x 
aX  1‘lA‘lEi  =>  “x  E  x 

‘x&x  A‘y&y  =>  ‘x  U  ‘y  E  x  u  y  (for  sets  or  bags) 
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Notations  on  Histories. 

Definition  2  (/).  Given  a  (finite)  sequence  Seq  and  a  set  S,  Seq/S  represents 
the  subsequence  of  Seq  for  indexes  in  S: 

\Seqf S\  =  card([l..|5eg|]  fl  S)  and 

(Vfc  :  1  ^  k  ^  \Seq/S\  :  ( Seq/S)[k ]  =  S'eq,[{minn  :  card(5  fl  [l..n])  ^  k  :  n)]) 

|5eg|  denotes  the  length  of  sequence  Seq.  Note  that  we  do  not  force  values  in 
S  to  be  valid  indexes  of  Seq.  Actually,  the  condition  under  which  k  is  a  valid 
index  of  Seq/S  is  1  ^  k  ^  |S'eg|  A  k  €  S. 

Definition  3  (Etc)-  Given  a  binary  relation  1Z,  we  define  the  corresponding 
weak  prefix  relationship,  denoted  by  Etc  • 

Q  Etc  Q'  =  IQI  ^  \Q'\  A  (Vfc  :  1  ^  k  \Q\  :  Q[k\  U  Q'[k]) 

Note  that  E=  is  the  traditional  prefix  relationship.  In  the  paper,  we  are  only 
using  Esj  and  E^  on  sequences  of  integers. 

Definition  4  (^). 

Given  S  and  S'  in  2IN: 

S  S'  =  5  C  S'  A  (Vx  :  x  G  S'  A  x  $  S  :  (Vj/  :  y  €  5  :  y  ^  x)) 

S  ^  S'  strengthens  the  subset  relation  5  C  S'  by  forcing  the  additional  values 
in  S'  to  be  greater  than  all  values  in  S.  An  alternative  definition  could  be: 

S^S'  =  <VQ  ::  Q/S  E  Q/S') 

Definition  5  ( B ).  We  denote  by  B{Q)  the  bag  of  the  values  in  sequence  Q. 
Note  that  function  B  is  monotonic. 

3  The  Resource  Allocation  Example 

3.1  The  Different  Steps  of  the  Design 

We  suppose  we  want  to  design  a  resource  allocation  system:  we  want  some  clients 
to  handle  correctly  some  shared  resources. 

In  a  first  step,  we  specify  formally  what  the  clients  are  doing  with  respect 
to  these  resources  (spec.  [3])  and  what  the  correctness  constraints  of  the  sys¬ 
tem  are  (spec.  [2]).  We  deduce,  in  a  systematical  way,  how  a  resource  allocator 
should  behave  to  provide  that  correctness  (spec.  [4]).  We  then  pick  some  generic 
network  specification  (spec.  [5])  and  make  a  compositional  proof  to  show  that 
if  all  components  satisfy  their  specifications,  the  system  global  correctness  is 
guaranteed  (proof  Cl  sect.  4.2). 
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Now,  we  have  to  design  a  resource  allocator  satisfying  the  previous  spec¬ 
ification.  We  come  with  the  idea  that  such  an  allocator  can  be  built  from  a 
simpler  single-client  allocator  and  some  generic  components  (possibly  found  in 
a  component  library).  So,  we  specify  how  the  single-client  allocator  should  be¬ 
have  (spec.  [10]),  pick  a  generic  merge  component  (spec.  [6]),  a  generic  distrib¬ 
utor  component  (spec.  [7])  and  connect  all  these  components  with  a  network 
(spec.  [8]).  We  obtain  an  allocator  that  enjoys  additional  properties,  compared 
to  the  allocator  we  need  for  our  system.  Since  such  properties  may  be  reused 
later  in  another  design,  we  specify  formally  this  resulting  allocator  (spec.  [9]) 
and  prove  that  it  is  actually  obtained  from  the  chosen  components  (proof  C2 
sect.  B.2).  We  also  prove  that  this  allocator  implements  the  allocator  we  needed 
(proof  Rl  sect.  5.3). 

To  complete  the  development,  we  have  to  design  a  client  program  and  a 
single-client  allocator  program.  Starting  from  the  specifications  we  obtained  ([3] 
and  [10]),  we  write  two  programs  we  hope  to  satisfy  the  given  specifications.  We 
observe  that  the  resulting  programs  (prog.  sect.  6.1  and  prog.  sect.  7.1)  have 
more  properties  than  requested.  Again,  since  such  properties  can  be  reused,  we 
express  formally  these  behaviors  (spec.  [11]  and  spec.  [12]),  prove  that  the  texts 
satisfy  these  specifications  (proofs  T1  sect.  6.3  and  T2  sect.  D.3)  and,  of  course, 
that  these  specifications  are  stronger  than  requested  (proofs  R2  sect.  C.2  and 
R3  sect.  C.3). 

The  different  steps  of  this  design  are  summarized  in  fig.  1. 


3.2  Notations 

Resources  are  described  with  anonymous  tokens.  All  the  messages  exchanged 
between  the  resource  allocator  and  its  clients  have  the  same  type:  integer  (the 
number  of  tokens  requested,  given  or  released).  Tokens. h  is  the  total  number  of 
tokens  in  history  h  (i.e.  Tokens.h  =  X]L=i  h[k]). 

All  clients  have  the  same  generic  behavior.  They  send  requests  for  resources 
through  a  port  ask,  receive  these  resources  through  a  port  giv,  and  release  the 
resources  through  a  port  rel.  Clients  variables  are  prefixed  with  Client *.  The 
allocator  has  three  arrays  of  ports,  ask,  giv  and  rel,  prefixed  by  Alloc.  A  network 
is  responsible  for  transporting  messages  from  Clienti.ask  to  Alloc. aski,  from 
Alloc. givi  to  Clienti.giv,  and  from  Clienti.rel  to  Alloc. reU.  A  valid  initial  state 
is  a  state  where  all  ports  histories  are  empty  and  where  the  resource  allocator 
has  a  stock  of  NbT  tokens. 

4  From  a  Resource  Allocation  System  towards  an 
Allocator  and  Clients 

4.1  Components  Specifications 

The  global  correctness  we  want  for  the  resource  allocation  system  is  expressed 
in  a  very  traditional  way.  A  safety  property  states  that  clients  never  share  more 
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tokens  that  there  exists  in  the  system.  A  liveness  property  guarantees  that  all 
client  requests  are  eventually  satisfied  (Fig.  2). 


always  '^2j(Tokens.  Client i.giv  —  Tokens .Clienti.rel)  ^  NbT  (1) 

Vi, /i  ::  ft  C  Clienti.ask  ft  Clienti.giv  (2) 

Fig.  2.  Resource  allocation  system  specification. 


Clients  specification  is  also  very  intuitive.  The  safety  part  is  that  clients  never 
ask  for  more  tokens  that  there  exist  (such  requests  would  not  be  satisfiable) . 
The  liveness  part  guarantees  that  clients  return  all  the  tokens  they  get,  when 
these  tokens  are  satisfying  a  request  (unrequested  tokens  or  tokens  in  insufficient 
number  may  not  be  returned)  (Fig.  3). 


true  guarantees  ask  /*  A  rel  /*  (3) 

true  guarantees  always  (Vfc  ::  ask[k]  ^  NbT )  (4) 

giv  guarantees  Vft  ::liC  giv  Ah  Cj,  ask  Tokens. rel  ^  Tokens. h  (5) 

Fig.  3.  Client  specification  (required). 


The  allocator  specification  is  almost  derived  from  the  client  specification. 
In  particular,  there  is  a  strong  correspondence  between  the  right-hand  sides  of 
clients  guarantees  and  the  left-hand  side  of  the  allocator  guarantees.  The  global 
safety,  which  is  the  responsibility  (mostly)  of  the  allocator  appears  also  in  the 
specification  (Fig.  4). 


true  guarantees  Vi  ::  givi  /*  (6) 

(Vi  ::  reli  /*)  guarantees  always  ^2{(Tokens .givi  —  Tokens. reh)  ^  NbT  (7) 
Vi  ::  aski  /*  A  reh  /* 

A  always  (Vi,  A:  ::  aski[k]  ^  NbT ) 

A  Vi,  ft  ::  hi  □  givi  A  hi  aski  Tokens. reh  ^  Tokens. hi  (8) 

guarantees 

Vi,  ft  ::  ft  C  aski  |-t  ft  givf 
Fig.  4.  Allocator  specification  (required). 
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The  network  specification  relies  on  the  follows  operator.  Output  ports  are 
connected  to  corresponding  input  ports  with  E  which  provides  both  safety  and 
liveness  (Fig.  5). 


Vi  :: 

Clienti.ask  /*  guarantees  Alloc. aski  Clienti.ask 
Alloc. givi  /*  guarantees  Clienti.giv  E  Alloc. givi 
Clienti.rel  /*  guarantees  Alloc. rel »  E  Clienti.rel 

Fig.  5.  Network  specification. 


(9) 


4.2  Composition  Proof 
Property  (1). 

Proof.  In  resource  allocation  system: 

{Specification  (3)} 

Vi ::  Clienti.rel 

=>  {Specification  (9),  follows  definition) 

Vi  ::  Alloc. reli 
=>•  {Specification  (7)} 

always  J2  i(Tokens.  Alloc,  givi  —  Tokens  .Alloc. reh)  ^  NbT 
=>  {Specifications  (6),  (3)  and  (9),  follows  theorems) 

always  ^T(ToA;ens.C7ienfj.<?i?j  —  Tokens. Clienti.rel)  ^  NbT 

□ 

Property  (2). 

Proof.  In  resource  allocation  system: 

{Specification  (3)} 

Vi ::  Clienti.ask  /*  A  Clienti.rel  /* 

=>  {Specification  (9),  follows  definition) 

Vi ::  Alloc,  aski  /*  A  Alloc. reli  Z' 

=$■  {Specification  (4)} 

Vi ::  Alloc. aski  Z  A  Alloc. reli  Z 
A  Vi  ::  always  (Vfc  ::  Client  * .  ask  [fc]  ^  NbT) 

=>  {Specification  (9),  follows  definition,  calculus) 

Vi ::  Alloc. aski  Z  A  Alloc. rek  Z 
A  always  (Vi,  k  ::  Alloc. aski[k]  ^  NbT) 

=>  {Specification  (6)} 

Vi ::  Alloc. aski  Z  A  Alloc. rek  Z 
A  always  (Vi,  k  ::  Alloc. aski[k]  ^  NbT) 

A  Vi  ::  Alloc. giVi  Z 

=>•  {Specification  (9),  follows  definition) 
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Vi ::  Alloc. aski  /*  A  Alloc.relj  /• 

A  always  {Vi,  ft  ::  Alloc. askj[k]  ^  IVftT) 

A  Vi  ::  Client i.giv  /* 

=>  {Specification  (5)} 

Vi ::  Alloc. aski  f*  A  Alloc.relj  /* 

A  always  (Vi,  k  ::  Alloc. askj[k]  ^  AftT) 

A  Vi,  h  ::  hi  C.  Clienti.giv  A  hi  Clienti.ask  Tokens. Clienti.rel  ^  Tokens.hi 
=>  {Specification  (9),  follows  definition,  transitivity  of  4  } 

Vi ::  Alloc. aski  /*  A  Alloc. reli  /* 

A  always  {Vi,  fc  ::  Alloc. askj[k]  ^  AftT) 

A  Vi,  ft  ::  hi  E  Alloc. givt  A  ft*  E^  Alloc. aski  •->  Tokens. Alloc. reli  ^  Tokens.hi 
=>  {Specification  (8)} 

Vi,  ft  ::  ft  E  Alloc. aski  •->  ft-  E^  Alloc. giVj 
=>  {Specification  (9),  follows  definition} 

Vi,  ft  ::  ft,  E  Clienti.ask  ft,  E^  Clienti.giv 

□ 


5  From  a  Single-Client  Allocator  to  a  General  Allocator 

5.1  Components  Specifications 

The  first  component  we  use  is  a  fair  merge.  It  merges  N  input  channels  (In)  into 
one  output  channel  (Out).  Furthermore,  it  provides,  for  each  output  message, 
the  number  of  the  channel  where  it  comes  from  (iOut)  (Fig.  6).  This  merge 
component  is  assumed  to  be  fair:  No  input  channel  can  be  ignored  indefinitely. 
A  merge  component  is  nondeterministic. 
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The  main  merge  specification  is  (13).  But  since  this  specification  only  con¬ 
straints  values  when  indexes  are  present  (and  indexes  when  values  are  present), 
we  force  that  there  is  no  value  without  the  corresponding  index,  and  no  index 
without  the  corresponding  value  (11).  Moreover,  specification  (13)  does  not  con¬ 
straint  values  corresponding  to  nonvalid  indexes.  So,  we  force  that  there  is  never 
a  nonvalid  index  (12).  Finally,  these  specifications  force  the  output  to  be  mono¬ 
tonic  in  length  only  (some  value  may  still  be  replaced  by  another,  changing  the 
corresponding  index  at  the  same  time).  Therefore,  we  add  the  constraint  (10). 
We  obtain  the  specification  in  fig.  6. 

The  distributor  component  is  the  symmetric  of  the  merge:  Given  a  valid  index 
in  iln  and  a  value  in  In,  it  outputs  the  value  in  the  right  output  queue  Outi 
(Fig.  7).  A  distributor  component  is  assumed  to  be  fair:  If  indexes  are  present, 
the  input  channel  cannot  be  ignored  indefinitely.  A  distributor  component  is 
deterministic. 


The  distributor  main  specification  is  similar  to  the  corresponding  merge  spec¬ 
ification  (Fig.  7).  One  important  difference  is  the  left-hand  side  of  the  guarantees : 
We  have  to  assume  that  the  indexes  provided  in  iln  are  correct.  The  difficulties 
we  had  with  the  merge,  leading  us  to  add  several  specifications,  do  not  appear 
here.  In  particular,  the  monotonicity  of  outputs  is  a  theorem  (22). 

We  now  combine  these  merge  and  distributor  components  with  a  simple 
allocator  that  only  deals  with  a  unique  client.  The  requests  are  merged  towards 
this  simple  allocator.  Their  origins  are  transfered  directly  to  a  distributor  which 
is  responsible  for  sending  the  tokens  given  by  the  allocator  to  the  right  addresses. 
Releases  are  also  merged  towards  the  simple  allocator.  Their  origins  are  not  used. 
All  four  components  are  connected  via  a  network  described  with  follows  relations 
(Fig.  8). 

The  allocator  we  build  from  this  composition  provides  a  specification  stronger 
than  the  required  specification  [4].  The  difference  is  that  the  origin  of  releases 
is  completely  ignored.  Therefore,  the  resulting  allocator  only  cares  about  the 
total  number  of  tokens  coming  back.  This  allows  clients  to  exchange  tokens  and 
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Fig.  8.  General  allocator  architecture  and  network  specification. 


a  client  can  return  tokens  received  by  another  client.  This  leads  to  a  weaker 
assumption  in  the  left-hand  side  of  the  liveness  property  (Fig.  9). 


true  guarantees  Vi  ::  givi  /*■  (15) 

(Vi  ::  reli  /*)  guarantees  always  '^2i(Tokens.givi  —  Tokens. reli)  ^  NbT  (16) 
Vi  ::  aski  A  reli  /*■ 

A  always  (Vi,  A;  ::  aski[k]  ^  NbT) 

A  Vh  ::  (Vi  ::  hi  C  givi  A  hi  aski )  e-t  Tokens. reli  ^  Tokens.hi  (17) 

guarantees 

Vi,h  ::  h  C  aski  h  givi 
Fig.  9.  Allocator  specification  (provided). 


The  previous  construction  relies  on  a  single-client  allocator.  Its  specification 
is  derived  from  specification  [9]  for  N  =  1  (Fig.  10). 

5.2  Basic  Properties 

In  this  section,  we  state  some  basic  properties  satisfied  by  the  merge  and  distrib¬ 
utor  components.  We  can  either  consider  them  as  lemmas  in  the  compositional 
proof,  or  as  additional  specifications  provided,  for  instance,  by  a  previous  use  of 
these  components  (see  conclusions). 

Merge  Component.  The  following  formula  states  that  the  output  (in  terms  of 
bags)  follows  the  input  of  a  merge.  In  other  words,  there  are  always  less  messages 
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true  guarantees  giv  Z  (18) 

rel  Z  guarantees  always  Tokens. giv  —  Tokens .rel  ^  NbT  (19) 

ask  Z  A  rel  Z 

A  always  (Vfe  ::  ask[k]  ^  NbT) 

A  Vft  ::  h  C  giv  A  h  Cj.  ask  i-»  Tokens. rel  ^  Tokens.h  (20) 

guarantees 
V/j  ::  h  C  osfc  i-»  h 

Fig.  10.  Single-client  allocator  specification  (required). 


on  the  right  of  a  merge  than  on  the  left,  but  some  liveness  works  at  reducing 
that  difference. 

(Vi  ::  Irii  Z)  guarantees  B(Out)  E  [J  B(Irii)  (21) 

i 

Proof.  See  appendix  A.l  □ 


Distributor  Component.  This  property  states  the  monotonicity  of  outputs: 

In  Z  A  iln  Z  A  always  (Vfc  ::  0  ^  iln[k]  <  N) 

guarantees  (22) 

Vi  ::  Outi  Z 

Proof.  See  appendix  A. 2  □ 

The  following  property  corresponds  to  property  (21)  for  the  merge: 

In  Z  A  iln  Z  A  always  (Vfc  ::  0  <  iln[k]  <  N) 

guarantees  (23) 

Ui  B(Outi)  E  B(In/{k  |  1  ^  k  ^  |i/n|}) 

Proof  See  appendix  A. 2  □ 


5.3  Refinement  Proof 

We  need  to  show  that  the  provided  specification  [9]  is  stronger  that  the  required 
specification  [4].  The  only  proof  obligation  is  that  (17)  =>•  (8).  Since  the  right- 
hand  sides  are  the  same,  we  have  to  prove  that  the  left-hand  side  of  (8)  is  stronger 
that  the  left-hand-side  of  (17). 
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Proof. 

{lhs  of  (8)} 

Vi.  h  ::  hi  C  givt  A  hi  aski  t-*  Tokens. reli  ^  Tokens. hi 
=>  {re/j  /*,  Tokens. reli  /*,  PSP} 

V/i  ::  (Vi  ::  /i*  C  A  hi  Cj,  asfcj)  h->  (Vi  ::  Tokens. reli  ^  Tokens. hi) 

=>  {calculus} 

Vh ::  (Vi  ::  hi  C  A  hi  Cj,  asAq)  *->  JT  Tokens. reli  ^  Tokens.hi 
{lhs  of  (17)} 

□ 


The  composition  proof  is  given  in  appendix  B.2 


6  Clients 

6.1  Model 

A  client  handles  a  variable  T  which  is  randomly  chosen  between  1  and  NbT 
and  which  represents  the  size  of  the  next  request.  Requests  for  tokens  are  built 
by  appending  the  value  of  T  to  the  history  of  requests.  There  is  exactly  one 
rel  message  produced  for  each  giv  message  received  that  satisfies  the  condition 
(enough  tokens  to  serve  the  request).  Such  a  client  can  send  several  requests 
before  one  request  is  answered,  and  can  receive  several  answers  before  it  releases 
one. 

Program  Client 
Declare 

giv  :  input  history, 
ask,  rel  :  output  history, 

T  :  bag  of  colors', 

Initially 

1  <  T  ^  NbT; 

Assign  (weak  fairness) 

rel  :=  rel  •  giv[\rel\  +  1]  if  |re/|  <  \giv\  A  giv[\rel\  +  1]  ^  osfc[|re/|  +  1] 

Assign  (no  fairness) 

[  T  ■.=  (T  mod  NbT) +  1 
[  ask  :=  ask  •  T 

End 


6.2  Provided  Specification 

The  client  model  provides  a  different  (and  stronger)  liveness  than  requested.  It 
is  only  requested  that  clients  return  the  right  total  number  of  tokens.  However, 
this  client  always  return  all  the  tokens  corresponding  to  a  request  in  a  single 
message  (Fig.  11). 

The  refinement  proof  ([11]  =>  [3])  is  given  in  appendix  C.2 
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true  guarantees  ask  /*■  A  rel  /*  (24) 

true  guarantees  always  (V/c  ::  ask[k]  ^  NbT)  (25) 

giv  /•  guarantees  V/i  ::  h  C  giv  A  h  ask  i-»  h  C  rel  (26) 

Fig.  11.  Client  specification  (provided). 


6.3  Correctness  Proof 
Property  (24).  Inductive  and  local. 

Property  (25).  The  program  satisfies  the  following  inductive  invariant: 

invariant  (Vfc  ::  ask[k]  ^  NbT)  A  (T  ^  NbT) 
which  is  local  and  stronger  than  the  required  always  property. 


Property  (26). 

Lemma  27. 

V/i,  k  ::  transient  rel  =  k  A  k  C  h  A  h  C  giv  A  h  ask  ■  Client  (27) 
Proof.  We  use  the  fact  that  (transient  q)  A  [p  =>  q]  =>•  (transient  p): 

rel  =  k  Ak  h  A  h  C  giv  A  ft  Cj,  ask 
=>  {Definition  of  Cj,,  calculus) 

rel  =  k  A  |rel|  <  |fi|  ^  A  (Vn  :  1  ^  n  ^  |fi|  :  <7*w[n]  ^  asfc[n]) 

=4>  {Calculus} 

rel  =  k  A  |rel|  ^  A  (Vn  :  1  ^  n  ^  |re/|  +  1  :  ^  osfc[n]) 

=>  {Choose  n  =  |rel|  +  1} 

rel  =  k  A  |rel|  ^  A  <?*u[|rel|  +  1]  ^  asfc[|rel|  +  1] 

{From  the  first  program  statement) 
is  transient  for  any  k 

□ 


Proof  (specification  (26)).  In  any  composed  system: 

{From  lemma  (27),  existentiality  of  transient} 

( rel  =  kAk\lhAhQgivAh  Cj,  ask) 
i->  -i  (rel  =  kAknhAhQgivAh  Cj,  ask) 

=>  {giv  /•  from  lhs,  ask  Z\  PSP) 

rel  =  k  Ak  c  h  Ah  C.  giv  Ah  Cj.  asfc  rel  ^  k 
=>  {rel  />,  PSP) 

rel  =  k  Ak  \z  h  Ah  Q  giv  Ah  Cj.  asfc  fee  rel 
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=>  {Induction  on  |h|  —  \k\} 

rel  =  k  /\k  c  h  A  h  C  giv  A  h  ask  (->■  rel  =  h 
=>  {Weakening} 

rel  =  k  Ak  \z  h  Ah  C  giv  Ah  ask  t ->  ft  C  re/ 

=>  {Disjunction  over  k} 

rel  C  h  A  h  C  giv  A  ft  Cj,  ask  i->  ft  C  rel 
=>  {Disjunction  [(p  A  r  e-4  q)  =>  ((p  V  q)  A  r  g)]} 

( rel  c  h  V  h  C  rel)  A  hQ  giv  Ah  asfc  4  ft  C  rel 

{always  re/  C  giv  holds  in  system,  hence  h  C  giv  =>•  ( rel  c/iVftC  re/)} 
h  C  giv  Ah  asfc  ^  h  Q  rel 

□ 


7  The  Single-Client  Allocator 

7.1  Model 

The  allocator  uses  a  variable  T  to  store  the  number  of  available  tokens.  It  simply 
answers  an  unsatisfied  request  if  there  is  enough  tokens  in  T.  The  allocator  also 
looks  into  its  release  port  and  “consumes”  messages  to  increase  T.  It  keeps  track 
of  the  number  of  consumed  messages  in  NbR. 

Program  Alloc 
Declare 

ask,  rel  :  input  history, 
giv  :  output  history ; 

T  :  bag  of  colors ; 

NbR  :  int ; 

Initially 

T  =  NbT  A  NbR  =  0 
Assign  (weak  fairness) 

giv,T  :=  giv  •  ask[\giv\  +  1],  T  —  ask[\giv\  +  1] 
if  |osfc|  >  \giv\  AT)  osfc[|y«r|  +  1] 

|  T,NbR  ■=  T  +  rel[NbR  +  1],  NbR  +  1  if  \rel\  >  NbR 

End 


7.2  Provided  Specification 

The  previous  model  provides  a  specification  for  the  single  client  allocator  stronger 
than  the  required  specification  [10]. 

The  main  difference  is  that  this  allocator  waits  for  a  request  before  it  sends 
tokens  (30).  This  is  not  explicitly  required  in  specification  [10].  Especially,  we  can 
imagine  an  allocator  able  to  guess  some  clients  requests,  using,  for  instance,  some 
knowledge  that  several  clients  have  exactly  the  same  behavior  (client  i  asked  for 
n  tokens,  therefore  client  j  will  also  ask  for  n  tokens.).  The  only  constraint  is 
that  tokens  given  to  a  client  correspond  (possibly  in  the  future)  to  a  request  from 
that  client.  Then,  since  this  allocator  does  not  send  tokens  without  requests,  it 
can  expect  the  return  of  all  the  tokens  it  sent,  which  changes  the  left-hand  side 
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of  the  liveness  property  (31).  Intuitively,  this  leads  to  a  stronger  specification: 
Never  sending  tokens  without  request  and  expecting  the  return  of  all  tokens  is 
stronger  than  only  expecting  the  return  of  tokens  sent  in  response  to  a  request. 

The  second  (minor)  difference  is  that  this  allocator  always  gives  exactly  the 
right  number  of  tokens.  The  resulting  specification  is  summarized  in  fig.  12. 


true  guarantees  giv  Z  (28) 

rel  Z  guarantees  always  Tokens. giv  —  Tokens .rel  ^  NbT  (29) 

ask  Z  guarantees  always  giv  C  ask  (30) 

ask  Z  A  rel  Z 

A  always  (V/c  ::  ask[k\  NbT) 

A  V/c  ::  Tokens. giv  ^  k  >->■  Tokens.rel  ^  k  (31) 

guarantees 
Vh  ::  h  C  ask  i h  C.  giv 

Fig.  12.  Single-client  allocator  specification  (provided). 


The  refinement  proof  ([12]  =>  [10])  is  given  in  appendix  C.3.  The  program 
text  correctness  proof  is  given  in  appendix  D.3. 

8  Conclusions 

The  allocator  example  illustrates  the  need,  when  adopting  a  component-based 
design,  to  switch  between  top-down  and  bottom-up  approaches:  A  designer  has 
in  mind  the  global  (at  his  level)  system  he  wants  to  obtain.  He  deduces  some 
expected  components  behaviors.  Among  these  components,  some  are  generic  and 
he  can  expect  to  find  them  in  some  repository.  However,  he  will  have  to  design 
some  other  components  by  himself.  Such  a  design  can  be  compositional  again 
(Sect.  5),  or  he  can  just  program  them  in  a  traditional  way  (Sect.  6  and  7). 

While  building  these  components  (by  programming,  or  by  further  decom¬ 
position),  he  adopts  the  provider  point  of  view:  he  looks  at  what  he  gets  and 
expresses  it  logically.  The  provided  specification  and  the  required  specification 
need  not  be  the  same  and,  in  general,  they  are  different.  This  is  because  when 
specifying  a  required  behavior,  one  does  not  want  to  demand  too  much;  and 
on  the  other  hand,  when  programming  a  model,  one  does  not  try  to  obtain  the 
weakest  possible  solution.  If  the  user  and  the  provider  are  forced  to  share  some 
average  common  specification,  they  remain  unsatisfied:  “Why  should  I  ask  for 
things  I  don’t  need?” ,  “Why  should  I  hide  some  properties  my  program  has?” . 
Because  we  hope  for  reusability,  a  component  should  be  finally  published  with  its 
provided  specification,  as  well  as  with  different  weaker  specifications  (Fig.  13). 
One  advantage  in  publishing  these  weak  specifications  is  that  they  may  allow 
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a  reuse  of  the  component  while  avoiding  either  another  refinement  proof  or  a 
complex  compositional  proof  (using  directly  the  provided  specification).  These 
weaker  specifications  can  be  obtained  from  previous  uses  of  that  component. 
Another  possibility  is  that  the  component  implementor  invests  effort  in  prov¬ 
ing  several  specifications  of  his  component,  and  hence  reduces  the  work  of  the 
composer  who  can  use  the  most  convenient  specification. 


Fig.  13.  Multiple  use  of  a  component. 


As  we  see  on  the  example,  this  approach  requires  three  kinds  of  proofs:  com¬ 
positional  proofs,  to  deduce  the  correctness  of  a  system  (or  sub-system)  from 
components  correctness;  refinement  proofs  to  check  that  bottom-up  phases  pro¬ 
vides  components  stronger  than  requested  during  top-down  phases;  program  text 
correctness  proofs  to  relate,  at  the  bottom,  program  texts  to  logical  specifica¬ 
tions.  The  framework  we  are  using,  based  on  Unity,  extended  with  composition 
operators  ( guarantees )  and  some  communication  abstraction  (follows),  is  able 
to  handle  those  three  types  of  proofs,  while  remaining  in  the  minimalism  spirit 
of  Unity. 

Our  goal  being  to  build  distributed  systems  from  components,  it  is  very 
important  to  have  the  possibility  to  specify  components  in  terms  of  input  and 
outputs,  and  to  be  able  to  connect  them  formally  through  simple  proofs.  Mixing 
a  temporal  operator  like  follows  with  some  basic  sequences  properties  seems 
an  interesting  approach.  We  are  currently  investigating  how  far  this  approach 
can  go.  Especially,  we  would  like  to  express  both  traditional  functional  behaviors 
and  useful  nondeterministic  behaviors  (like  merge)  with  a  common  notation  that 
would  be  able  to  handle  their  interaction  nicely. 

Another  area  of  interest  is  universal  properties.  Throughout  the  allocator  ex¬ 
ample,  all  composition  aspects  are  handled  with  existential  properties.  Although 
it  it  easier  to  use  existential  properties  than  universal  properties,  it  seems  that 
they  can  become  insufficient  when  dealing  with  global  complex  safety  properties. 
We  are  currently  investigating  examples  involving  such  global  complex  safety 
properties  to  learn  more  about  universally-based  composition  [5]. 
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The  motivation  for  this  research  is  the  development  of  large  repositories  of 
software  components.  Designers  can  discover  implementations  of  components 
and  use  relatively  simple  compositional  structures  to  create  useful  software  sys¬ 
tems.  Widespread  deployment  of  such  repositories  may  be  years  away.  Never¬ 
theless,  we  believe  that  research  to  support  such  repositories  is  interesting  both 
because  it  offers  intellectually  stimulating  problems  and  because  it  is  useful. 

We  have  been  working  on  composition  in  which  shared  variables  are  modified 
only  by  one  component  and  read  by  others.  Further,  proofs  are  simplified  if  these 
shared  variables  have  a  monotonic  structure.  Existential  and  universal  property 
types  make  proof  obligations  very  clear,  and  these  property  types  yield  nice 
proof  rules  that  appear,  at  least  at  this  early  stage  in  our  investigation,  to  be 
well  suited  for  mechanical  theorem  provers.  We  have  started  a  collaboration  with 
Larry  Paulson  who  has  successfully  used  Isabelle  [7]  to  prove  the  correctness  of 
such  systems. 

Much  work  remains  to  be  done  to  achieve  our  goal  of  large  repositories  of 
software  components  with  their  proofs  of  correctness.  This  is  a  step  in  that 
direction. 
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(21) 


A  Basic  Properties  Proofs 

A.l  Merge 
Property  (21). 

(Vi  ::  Irii  Z)  guarantees  B(Out)  E  [J  B(Irii) 

i 

Proof. 

B(Out) 

=  {From  specification  (11),  \Out\  =  \iOut\} 

B(Out/{k  |  1  <  k  ^  \iOut\}) 

=  {From  specification  (12),  for  any  k: 

(3i  :  0  ^  i  <  N  :  iOut[k\  =  i)  =  true} 

B(Out/{k  |  1  ^  k  ^  \iOut\  A  (3i  :  0  ^  i  <  N  :  iOut[k\  =  i)}) 

=  {Calculus} 

B(Out/  Uilo1'^  |  1  ^  k  ^  \iOut\  A  iOut[k\  =  i}) 

=  {Sets  are  disjoint,  lemma  (42)} 

U^o1  &(Out/{k  |  1  <  k  ^  \iOut\  A  iOut[k]  =  i}) 

E  {From  specification  (13),  follows  theorems} 

UIo1^) 

□ 

A. 2  Distributor 
Property  (22). 

In  Z  A  iln  Z  A  always  (Vfc  ::  0  ^  iln[k\  <  N) 

guarantees  (22) 

Vi  ::  Outi  Z 

Proof.  From  specification  (14),  any  follows’  right-hand  side  being  monotonic. 

□ 


Property  (23). 

In  Z  A  iln  Z  A  always  (Vfc  ::  0  ^  iln[k ]  <  N) 

guarantees 

(Ji  B(Outi)  E  B(In/{k  |  1  ^  fc  ^  \Hn\}) 

Proof. 

_  U£o ^(OuU) 

E  {From  specification  (14)  and  follows  theorems} 

Uto1  B{In/{k  |  1  ^  fc  ^  \iln\  A  iln[k]  =  i}) 

=  {Sets  are  disjoint,  lemma  (42)} 

B(In/  U^Lo1"^  |  1  ^  fc  ^  \iln\  A  iln[k\  =  i}) 

=  {Calculus} 

B(In/{k  |  1  ^  fc  ^  \iln\  A  (3i  :  0  ^  i  <  N  :  iln[k\  =  i)}) 

=  {From  lhs,  (3i  :  0  ^  i  <  N  :  iln[k\  =  i)  =  true} 

B(In/{k  |  1  ^  fc  <  |i/n|}) 


(23) 
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□ 


B  Compositional  Proofs 

B.l  Cl 

See  sect.  4.2. 


B.2  C2 

Lemmas  and  Corollaries.  The  following  lemmas  and  corollaries  are  used  in 
the  proof.  For  any  binary  relation  7 Z,  any  sequences  Q,  ‘Q,  Q' ,  ‘Q1,  Q",  Q1",  any 
sets  S,  S',  and  any  predicate  P: 

Lemma  32. 

[Q  E  Q'  E n  Q"  E  Q"'  =>  Q  Etc  Q"'\  (32) 

Lemma  33.  IfIZ  is  an  order  relation  (reflexive,  transitive,  antisymmetric),  then 
Etc  is  an  order  relation. 

Lemma  34.  If  1Z  is  an  order  relation,  then: 

‘Q&Q  wrt  E  =>  ‘Q  E  Q  wrt  Etc  (34) 

Lemma  35. 

[Q  Etc  Q'  A  S  S'  =►  Q/S  Etc  Q'/S']  (35) 


Corollary  36. 


Q/n  A5/^  Q/S  / 1 


(36) 


Lemma  37. 


[QQQ'  =>  {k  |  1  k  |g|  A  P.Q[k]}  {k  |  1  k  |Q'|  A  P.Q'[k]}]  (37) 

Corollary  38. 

g  /*E  =>  {k  I  1  ^  k  ^  |g|  A  P.Q[k]}  (38) 

Corollary  39. 

g /t  a g'/E=>  g/{&  1 1  o  < |g'| a p.g'[fc]} (39) 

Lemma  40. 


g/t  a54  a ig e g  a  ise5  =>•  iq/‘S®q/s 

Corollary  41. 

g/t  a g'/B  A‘gig  a  ‘g'eg' 

=> 

*g/{fc  1 1  fc  |ig'|  a  p.ig'[fc]}  e  g/{&  1 1  k  ^  \q'\  ^  p.Q'[k]} 


(40) 

(41) 
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Lemma  42. 


[S  n  S'  =  0  =>  B(Q/S  U  S')  =  B(Q/S)  U  B(Q/S')]  (42) 

The  following  lemma  relates  the  bags  of  histories  to  the  number  of  tokens  in 
these  histories: 

Lemma  43  (bags  and  tokens  relationship).  For  any  queues  Q,  Q'  and  Q" : 

[B(Q)  =  B(Q')  =>  Tokens.Q  =  Tokens.Q ']  , .  . 

[j B(Q )  =  B(Q')  U  B(Q")  =>  Tokens.Q  =  Tokens.Q'  +  Tokens.Q "] 

In  the  remainder  of  the  proof,  variable  names  are  not  prefixed  with  compo¬ 
nent  name.  We  use  instead  the  names  of  fig.  8.  Properties  are  stated  for  the 
global  system. 

Proof  of  (15). 

Proof. 

{Inner  allocator  specification  (6),  merge  specifications  (10)  and  (12)} 
giv  y  AiA  y  A  always  (Vfc  ::  0  ^  iA\k]  <  N) 

=>  {Follows  definition,  weakening  E  into  C} 

Gy  A  iG  y  A  always  (Vfc  ::  0  ^  iG[k]  <  N) 

=>  {Distributor  specification  (22)} 

Vi  ::  giVi  y 

□ 


Proof  of  (16). 

Proof.  From  merge  specifications  and  follows  definition,  rel  y  and  specification 
(7)  is  applicable.  Then: 

J2i  Tokens. givi  —  J2i  Tokens. reU 
^  {From  distributor  property  (23),  using  lemma  (43)} 

Tokens. G  —  Tokens. reli 

^  {Weakening  G  E  giv  into  subbag  relation,  using  lemma  (43)} 

Tokens. giv  —  Tokens. reU 
^  {Same  work  on  rel,  using  merge  property  (21)} 

Tokens. giv  —  Tokens.rel 
^  {From  inner  allocator  specification  (7)} 

NbT 

□ 


Proof  of  (17). 

Lemma  44.  The  inner  allocator  is  live  (it  eventually  answers  any  request). 

Vfc  ::  h  C  ask  (->■  fc  giv  (44) 
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Proof.  We  show  that  the  lhs  of  (8)  is  satisfied: 

1.  ask  Z  A  rel  Z 

from  merge  specification  and  follows  definition. 

2.  always  (Vn  ::  ask[n]  ^  NbT) 

{From  lhs  of  (17)} 

always  (Vi , n  ::  aski[n]  ^  NbT) 

=>  {Definition  of  B(aski)} 

always  (Vi, x  :  x  €  B(aski)  :  x  ^  NbT) 

=>  {B(A)  E  1J iB(aski)  from  (21),  calculus} 
always  (Vx  :  x  £  B(A)  :  x  ^  NbT) 

=>  {Weakening  ask  E  A  into  subbag  relation} 
always  (Vx  :  x  G  B(ask)  :  x  ^  NbT) 

=>  {Definition  of  B(ask)} 

always  (Vn  ::  ask[n]  ^  NbT) 

3.  Vh  ::  h  C  giv  A  h  Cj.  asfc  Tokens. rel  ^  Tokens.h 

hQ  giv  Ah  Cj,  asA; 

=>  {Choice  of  a} 

h  Q  giv  A  h  Cj,  asA;  AiA  =  a 
h->  {From  iG  E  iA  and  monotonicity  of  histories} 
h  C  giv  Ah  Cj,  ask  A  a  C  id  A  a  C  iG 
=>•  {Notation:  hi  =  h/{k  \  1  ^  k  ^  |h|  A  a[A{  =  i},  lemma  (35)} 

(Vi  ::  /ij  C  giv / {k  |  1  ^  k  ^  \h\  A  a  [A;]  =  i} 

A  /ij  Cj.  ask/{k  |  1  ^  A:  ^  \h\  A  a[A:]  =  i}) 

A  a  C  iA  A  a  C  iG 

=>•  {From  merge  specification  (11),  |h|  ^  |a|,  then  lemma  (35)} 

(Vi  ::  hi  Q  giv /{k  \  1  ^  k  ^  |a|  A  a[A:]  =  i} 

A  hi  ask/{k  |  1  ^  k  ^  |a|  A  a[A:]  =  i}) 

A  a  C  i^4  A  a  C  iG 

=>  {Using  aCii  and  a  C  iG,  lemmas  (37)  and  (35)} 

(Vi  ::  hi  Q  giv /{k  \  1  ^  k  ^  |iG|  A  iG[A;]  =  i} 

A  hi  ask/{k  |  1  ^  k  ^  \iA\  A  i^4 [A:]  =  i}) 

=£•  {Merge  specification  (13),  follows  liveness} 

(Vi  ::  hi  C  givt 

A  hi  ask / {k  \  1  ^  k  ^  \iA\ /\  iA[k]  =  i}) 

=>  {Merge  specification  (13),  weakening  E  into  C^} 

(Vi  ::  hi  C  givt  A  hi  aski) 

•->  {From  lhs  of  (17)} 

J2i  Tokens. reli  ^  J2i  Tokens.hi 
i  y  {From  merge  property  (21)  and  lemma  (43)} 

Tokens. rel  ^  J2i  Tokens.hi 
=>  {Using  J2i  Tokens.hi  =  Tokens.h} 

Tokens. rel  ^  Tokens.h 

□ 
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Lemma  45. 


S  =>  ( Vh,S  ::  h  C  ask/S  h-»  h  giv/S)  (45) 


Proof. 

{Lemma  (44)} 

Vfc  ::  k  C  ask  i->  k  giv 

=>  {Choosing  k  =  ask,  strengthening  lhs,  k/S  /*  from  corollary  (36)} 

Vh  ::  h  C  ask/S  A  ask  =  k  i->  hQk/ S  A  A;  giv 
=>  {Lemma  (35)} 

V7i  ::  h  C  ask/S  A  asA;  =  fc  hQk/ S  A  A;/ S  giv/S 
=>  {Lemma  (32)} 

Vh  ::  h  Q  ask/S  A  asA;  =  A  i->  At  giv/S 
=>  {Disjunction} 

Vh  ::  ft  C  ask/S  h->  h  giv/S 

□ 


Proof  (specification  (17)). 
h  C  as  A* 

t->  {asfcj  /*,  merge  specification  (13),  follows  liveness} 
h  C  ^4/{A  |  1  ^  A  ^  |i.A|  A  i^4[A]  =  i } 

{asfc  E  A,  iGtS  iA,  corollary  (41),  follows  liveness} 
h  C.  ask/{k  |  1  ^  k  ^  \iG\  A  iG[k\  =  i} 

{Lemma  (45)} 

h  giv/ {k  |  1  ^  k  ^  |iG|  A  iG[fc]  =  i} 

{From  distributor  specification  (14),  lemma  (34),  follows  liveness} 
h  Es?  giVi 

□ 


C  Refinement  Proofs 


C.l  R1 

See  sect.  5.3. 


C.2  R2 

We  need  to  show  that  the  provided  specification  [11]  is  stronger  that  the  required 
specification  [3].  The  only  proof  obligation  is  that  (26)  =>  (5),  which  is  trivial 
since 

[h  C  rel  =>  Tokens. rel  ^  Tokens. h] 
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C.3  R3 


We  need  to  show  that  the  provided  specification  [12]  is  stronger  that  the  required 
specification  [10].  The  only  proof  obligation  is  that  [12]  =>•  (20). 

Lemma  46. 

[12]  A  Ihs  of  (20)  =>  (Vfc  ::  Tokens.giv  ^  k  i->  Tokens. rel  >  k)  (46) 

Proof. 

Tokens.giv  ^  k 
=>  {Choice  of  fc} 

Tokens.giv  ^  k  A  giv  =  h 

=>  {ask  from  ihs  of  (20),  use  specification  (30)} 

Tokens.giv  ^  k  /\  giv  =  h  /\hQ  ask 
i->  {From  Ihs  of  (20)} 

Tokens. rel  ^  Tokens. h 
=>  {From  Tokens. h  >  k} 

Tokens. rel  ^  k 

□ 

Proof  (specification  (20)).  Assuming  [12]: 

Ihs  of  (20) 

=>  {Lemma  (46)} 

Ihs  of  (20)  A  (Vfc  ::  Tokens.giv  ^  fc  Tokens. rel  ^  fc) 

=>  {Calculus} 

Ihs  of  (31) 

guarantees  {Using  (31)  from  [12]} 

Vfc  ::  h  C.  ask  t hC.  giv 
=>  {Weakening  C  into  C^} 

rhs  of  (20) 

□ 

D  Text  Correctness  Proofs 

D.l  Lemma  for  Proving  Guarantees 

The  following  lemma  is  useful  when  proving  some  guarantees  properties  from  a 
component  program  text.  It  allows  us  to  derive  a  (weak)  system  property  (right- 
hand  side  of  a  guarantees )  from  a  strong  local  property  (from  the  program  text), 
a  weak  system  property  (left-hand  side  of  the  guarantees )  and  a  strong  system 
property  (from  locality  hypotheses). 

Lemma  47.  Given  programs  F  and  G,  and  predicate  P,  the  following  rule  holds: 

stables  P.x.y  ■  F 

Vfc  ::  stable^  P.k.y  ■  F^G  .  . 

Vfc  ::  stables  x  =  fc  •  G 
stable^,  P.x.y  ■ 
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Proof. 

(stables  P.x.y  ■  F)  A 

(VA;  ::  stable,,,  P.k.y  ■  F[]G)  A 

(VA;  ::  stables  x  =  k  ■  G) 

=>•  {Translating  stable  into  next} 

( P.x.y  nexts  P.x.y  ■  F)  A 

(VA;  ::  P.k.y  next,,,  P.k.y  ■  P[]G)  A 

(VA;  ::  x  =  k  nexts  x  =  k  ■  G) 

=>  {lhs  strengthening,  rhs  weakening  of  next} 

(VA;  ::  x  =  k  A  P.x.y  nexts  x  =  k  V  P.x.y  ■  F )  A 

(VA;  ::  P.A;.y  next,,,  P.A;.y  •  F|G)  A 

(VA;  ::  x  =  k  A  P.x.y  nexts  x  =  A;  V  P.x.y  •  G) 

=>  {Universality  of  nexts} 

(yk  ::  x  =  k  A  P.x.y  nexts  x  =  k  V  P.x.y  •  P|]G)  A 
(VA;  ::  P.A;.y  next,,,  P.k.y  ■  P|]G) 

=>  {Conjunctivity  of  next} 

Vk  ::  x  =  k  A  P.x.y  A  P.k.y  next,,,  (x  =  A'  V  P.x.y)  A  P.A;.y  •  F[]G 
=>•  {Predicate  calculus:  lhs  =  (x  =  k  A  P.x.y),  rhs  =>  P.x.y} 

VA;  ::  x  =  A;  A  P.x.y  next,,,  P.x.y  •  F[]G 
=>•  {Disjunctivity  of  next} 

(3A;  ::  x  =  k  A  P.x.y )  next,,,  P.x.y  •  F[G 
=>  {Predicate  calculus} 

P.x.y  nextff  P.x.y  •  P[]G 
=>  {Translating  next  into  stable} 
stable,,,  P.x.y  ■  P[]G 

□ 


D.2  T1 

See  sect.  6.3. 

D.3  T2 

Property  (28).  Inductive  and  local. 


Property  (29). 

Proof. 

{From  program  text} 

stables  T^O  -Alloc 

stables  NbR  ^  | re/ 1  -Alloc 

stables  T  =  NbT  —  Tokens. giv  +  rel[i]- Alloc 

=>  {Let  x  =  ( T,  NbR,  giv)  and  y  =  rel  and  NbR 

P.x.y  =  (T  ^  0)  A  (NbR  ^  | reZ | )  A  (T  =  NbT  -  Tokens. giv  +  E  «'H)} 

i—1 
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stables  P.x.y  ■  Alloc 
=>  {From  locality  and  lhs  of  (29)} 
stables  P.x.y  ■  Alloc 

A  (Vfc  ::  stable^  P.k.y  ■  Alloc\env)  A  (Vfc  ::  stables  x  =  k  ■  env ) 

=>  {Lemma  (47)} 

stable^,  P.x.y  ■  Alloc\env 

=>  {Histories  are  empty  in  initial  state,  assume  NbT  ^  0} 
always  P.x.y  ■  Alloc^env 
=>  {Expanding  predicate  P} 

always 

( T  >  0)  A  (NbR  s$  \rel\)  A  ( T  =  NbT  -  Tokens. giv  +  rel[i\)  (48) 

■Alloc\env 

=>  {From  [NbR  ^  \rel\  =>  reA^\  ^  Tokens .rel]} 

always  Tokens. giv  —  Tokens. rel  ^  NbT  ■  Alloc\env 


□ 


Property  (30). 

Proof.  Let  x  -  ■  giv,  y  =  ask  and  P.x.y  =  x  C  y. 

{From  program  text} 
stables  P.x.y  ■  Alloc 
=>  {From  locality  and  lhs  of  (30)} 
stables  P.x.y  ■  Alloc 

A  (Vfc  ::  stable^,  P.k.y  ■  Alloc\env )  A  (Vfc  ::  stables  x  =  k  ■  env ) 

{Lemma  (47)} 
stable,,,  P.x.y  ■  Alloc\env 
=>•  {Histories  are  empty  in  initial  state} 
always  P.x.y  ■  Alloc[env 
=>  {Expanding  predicate  P} 
always  giv  C  ask  ■  Alloc\env 

□ 


Property  (31).  All  the  following  properties  are  stated  for  Alloc\env ,  including 
transient  properties  that  come  from  the  corresponding  transient  property  in 
Alloc  alone. 

Lemma  49. 

Vfc  ::  |re/|  ^  fc  NbR  ^  fc  (49) 
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Proof. 

{From  program  text} 

VA  ::  transient  \rel\  ^  A  A  NbR  =  k  —  1 
=>  {Using  stable  | reZ |  ^  k  (from  lhs  of  guarantees ),  PSP} 

VA  ::  \rel\  ^  k  A  NbR  =  k  —  1  NbR  ^  k  -  1 
=>  {Using  stable  NbR  ^  A;  (from  program  text),  PSP} 

VA  ::  | reZ |  ^  k  A  =  A  —  1  i->  iV6i?  ^  A; 

=>  {Induction  over  n,  using  the  previous  property} 

Vn,  k  ::  \rel\  ^  k  A  IV6i?  =  n  iVAi?  ^  A: 

=>  {Disjunction  over  n} 

VA  ::  |re/|  ^  A;  i-»  IV  W?  ^  A; 

□ 

Lemma  50. 

VA  ::  ask[\giv\  +  1]  A  |asA|  >  \giv\  =  k  \giv\  >  k  (50) 

Proof.  Similar  as  for  (49).  □ 

Lemma  51. 

NbR 

always  ^  rel[i\  ^  Tokens. giv  =>  NbT  (51) 

i= 1 

Proof.  From  ask  /*  and  rel  /*  in  the  left-hand  side  of  the  guarantees,  we  can 
use  the  right-hand  side  of  (48)  (proved  under  the  hypothesis  rel  /) ,  from  which 
the  required  property  follows  trivially.  □ 

Proof  (property  (31)). 

{From  lhs  of  guarantees,  giv  /*,  PSP,  predicate  calculus} 

\giv\  =  n  A  Tokens. giv  =  k  (| \giv\  =  n  A  Tokens. giv  =  k  A  Tokens. rel  ^  A)  V  \giv\  >  n 

=>  {Lemma  (49)} 

\giv\  =  n  A  Tokens. giv  =  k  (\giv\  =  n  A  Tokens. giv  =  k  A  ^  A:)  V  >  n 

=>  {Lemma  (51)} 

=  n  A  Tokens. giv  =  k  t->  (|(?*u|  =  n  A  T  ^  NbT)  V  >  n 
=>  {Disjunction  over  A;} 

|5»|  =ni->  (|5*w|  =  IV&T)  V  |  t/i-u  |  >  n 

=>  {lhs  strengthening,  asA  /*,  PSP} 

|asA|  =  A:  A  =  n  <  A:  ( T  ^  IV&T  A  |asA|  >  |5«j|  =  n)  V  |5«j|  >  n 
=>  {ask[\giv\  +  1]  ^  NbT,  from  lhs  of  guarantees} 

|asA|  =  k  A  \giv\  =  n  <  k  (T  ^  asA[|<?M)|  +  1]  A  |asA|  >  =  n)  V  >  n 

=>  {From  lemma  (50)} 

|asA|  =  A;  A  |5*t)|  =  n  <  k  \giv\  >  n 
=>  {Induction  over  n} 

|asA|  =  A  \giv\  ^  k 
=>  {Disjunction} 

|asA|  ^  A  H-  |g*v|  ^  A 
=>  {Using  (30)} 

VA  ::  A  C  asA  nAC  giv 

□ 
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